Computer-Assisted Abstraction of Data and Document Coding

ABSTRACT

A computer-assisted method of abstracting and coding data includes receiving one or more documents is disclosed. The methods and systems extract information from a record based on extraction rules that correspond to an identified record type, determine codes corresponding to the information extracted from the record, present the correspondence between the extracted information and the codes, receive from the user-input device a validation of the correspondence between the extracted information and one of the codes, and output a report including the validated information and the validated code.

This application claims benefit of priority to U.S. Provisional PatentApplication No. 61/165,296, filed on Mar. 31, 2009, and 61/248,091 filedOct. 2, 2009. The disclosures of both Application No. 61/165,296 andApplication No. 61/248,091 are both hereby incorporated into thisspecification by reference in their entirety.

FIELD

The present disclosure relates generally to computer-assistedabstraction and coding of information.

BACKGROUND

Documents are frequently generated by transcribing dictated material.For instance, a user (e.g., a doctor) may speak information into adictation device and provide the dictation to a transcription servicewhich converts the dictation into a text document. In some cases,specific information may be “abstracted” from the document. For example,in healthcare applications, the transcription service may abstract thedocument by extracting a list of medications, allergies and/or qualitymeasures that are included in the document. In addition, the service mayassociate medical codes with some or all of the extracted data. Theextracted and coded information may be reviewed before being provided toan end-user such as an medical insurance provider. This process can bevery time consuming and expensive.

SUMMARY

Exemplary embodiments disclosed herein provide methods, systems anddevices for computer-assisted abstracting and coding of information. Theexemplary embodiments may extract information from a record based onextraction rules that correspond to an identified record type, determinecodes corresponding to the information extracted from the record,present the correspondence between the extracted information and thecodes, receive from the user-input device a validation of thecorrespondence between the extracted information and one of the codes,and output a report including the validated information and thevalidated code.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram illustrating an exemplary environment in whichsome embodiments may operate;

FIG. 2 is a flowchart illustrating an exemplary process; and

FIGS. 3A-5B illustrate exemplary graphical user interfaces.

DETAILED DESCRIPTION

FIG. 1 is a block diagram illustrating an exemplary environment in whichsome embodiments may operate. As illustrated, environment 100 mayinclude, a user 114, a dictation device 111, a host 110, a reviewer 118,a reviewer terminal 119, a validator 120 and a validator terminal 121.

User 114 can be any individual or entity that generates a document. Forinstance, user 114 can be an employee of a doctor's office, law firm oran insurance company who may desire to have dictation translated intotext. Alternatively, user 114 may be a company, a hospital, a law firman insurer or any other entity that generates documents.

Dictation device 111 can be any device for capturing information fromuser 114 such as a dictation machine, a telephone, a personal computer(e.g., desktop or laptop), a handheld recording device, a smart phone,or a personal digital assistant. Dictation device 111 also can be aspecial purpose device that allows user 114 to dictate, store and accessaudio/video files and documents for transmission to host 110.

Host 110 can be a device or system for receiving, storing, and/orprocessing documents received from user 114. The host can also be adevice for providing information to reviewer 118 and validator 120. Host110 can be implemented as one or more computer systems including, forexample, a personal computer, a minicomputer, a microprocessor, aserver, a workstation, a mainframe, or a similar computing platform.

Host 110 may be in communication with user 114, dictation device 111,reviewer 118, reviewer terminal 119, validator 120 and/or validatorterminal 121 via one or more communication channels (not shown). Thecommunication channels may be wired or wireless connections. In someinstances, the communication channels can be a direct link such as ananalog, a serial or a parallel interface. In other instances, thecommunication channels can be a shared, public, private, or peer-to-peernetwork, encompassing any wide or local area network such as anextranet, an intranet, the Internet, a Local Area Network (LAN), a WideArea Network (WAN), a virtual private network (VPN), a voice overinternet packet network (VoIP), a public switched telephone network(PSTN), an Integrated Services Digital Network (ISDN), or any other formof wired or wireless communication network.

Host 110 can include a controller 112 and data storage device 116. Inaddition, while not illustrated, controller 112 can include one or moreprocessors, computer-readable memory (e.g., read-only memory and randomaccess memory), in addition to other components such as a clock, acommunication interface, a data bus, an input/output device, auser-input device and a display device.

Computer-readable data storage device 116 may include any hardware,software, firmware, or combination thereof that stores and retrievesinformation, including computer-readable program instructions and data.Data storage device 116 may be, for instance, a semiconductor, magneticor optical-based information storage/retrieval device (e.g., flashmemory, hard disk drive, CD-ROM, flash RAM). Although data storagedevice 116 is depicted as a single element, device 116 may comprise anyadditional number of storage media. Although controller 112 and datastorage device 116 are shown as being within host 110, this location ismerely exemplary. Controller 112 and data storage device 116 can bephysically located inside or outside of host 110. For instance, datastorage device 116 can be configured as a network accessible storagedevice located remotely from controller 112.

Reviewer 118 can be one or more individuals, software systems, computersystems, or a combination thereof for reviewing abstracted data foraccuracy. Reviewer 118 can also include individuals who verify theaccuracy of abstractions performed by individuals or computer programsthat automatically perform the abstraction of data such as, coders,nurses, clinical document specialist and physicians. Only one reviewer118 has been shown for illustrative purposes. However, environment 100may include multiple reviewers of the same configuration.

Validator 120 can be one or more individuals, software systems, or acombination thereof for validating reviewed abstracted reports. In somecases, validator 120 performs quality control functions for atranscription service. In other cases, validator 120 may be an end userof the report, for instance, a doctor, nurse, coder, hospitaladministrator, lawyer or an insurance agent.

Terminals 119 and 121 can be data processing devices such as a remoteterminal, personal computer or network workstation. Terminals 119 and121 may include a processor, a data storage device and stored programinstructions that control the terminals to receive and displayinformation for reviewer 118 and validator 120. In some embodiments,terminals 119 an 121 may emulate the function of a terminal and allowconcurrent use of local programs and access to a remote terminal hostsystem.

Although user 114, dictation device 111, host 110, reviewers 118 andvalidator 120 are shown in FIG. 1 as separate elements, some or all ofthe elements can be combined or divided into fewer or greater number ofelements at one or more locations. The particular division of functionsis for illustration only, and different elements may perform one or moreof the functions disclosed above.

As shown in FIG. 1, host 110 may store computer-executable instructions(e.g., software, firmware, applications, programs, code, portions ofcode, and combinations thereof) and data (e.g., data compilations,databases, data sets) in data storage device 116 that, when retrievedand executed by controller 112, control host 110 to transcribe, abstractand/or code documents, as disclosed herein. The computer-executableinstructions can be encoded using any suitable computer programminglanguage such as, C++, JAVA and the SCALA. SCALA is a programminglanguage that supports both object-oriented computing and functionalprogramming.

Data storage device 116 may include a transcription application 122,abstraction application 124 and a workflow engine 119. Although notshown, data storage device 116 may include other computer-executableinstructions that control host 110 (e.g., a bootloader, an operatingsystem, control modules and hardware drivers). In addition, data storagedevice 116 can store transcribed documents, patient data, rules,database of medical codes, abstractions, validated reports, documents,manually generated documents, clarification notes and private data. Datastorage device 116 may also include a queue for storing reports ofabstracted data awaiting review by reviewers 118.

Transcription application 122, when executed by controller 112, controlshost 110 to transcribe documents received by the host. For instance,transcription application 122 may convert dictation and/or documentsreceived from user 114 or dictation device 111 into text that issearchable and/or editable. In some cases, transcription application 122may use voice recognition software to convert aural dictations intotext. In other cases, transcription application 122 may use opticalcharacter recognition (OCR) software to convert documents into text.Alternatively or additionally, transcription application 122 mayallocate the dictations or documents to human transcribers. In someinstances, human transcribers verify the transcriptions performed bytranscription application 122.

Abstraction application 124, when executed by controller 112, controlshost 110 to extract information from the transcribed documents andgenerates corresponding codes for the extracted information. Abstractionapplication 124 includes an extractor module 113 for extractinginformation from documents, a linker module 115 for associatingcorresponding codes to the extracted data, and a user interface module117 for presenting interactive graphic user interfaces.

Workflow engine 119, when executed by controller 112, controls host 110to process workflow information. Workflow engine 119 may includemultiple program modules for handling the workflow of data such as, areport generator process for generating a structured report of theextracted and coded data and presenting the structured report forend-user validation, a billing process for outputting data for billingand reimbursement, a quality measure process for outputting data forreporting quality measures, and an alert process for generating an alertwhen certain conditions are met.

FIG. 1 illustrates an exemplary information flow that may occur in someexemplary embodiments. For the sake of illustration, the examplediscussed below is directed to a system and/or service for transcribingpatient information received from a medical provider. Of course, thedisclosed embodiments are not limited to such examples and may beapplied to other systems and services.

In one example, user 114 may be a physician that dictates a patient'sinformation and diagnosis into a dictation device 111. Dictation device111 may convert the physician's spoken words into electronic form andprovide the dictation to host 110 over a communication channel.Dictation device 111 may provide the dictation to host 110 as a file(e.g., a single document), multiple files (e.g., multiple documents orportions of a document) or as a stream of information (e.g., streamingaudio). Additionally or alternatively, the physician, through dictationdevice 111 may transmit documents to host 110. Documents may be papers(e.g., facsimiles) or computer-readable files (e.g., text, spreadsheets,images, datasets, multimedia, sound and/or video). For instance, when apatient is receiving care at a medical facility, many documents aregenerated related to the patient such as, progress notes, procedurelists, lab results, medical histories, physical examination reports, andconsultation referrals. These documents can submitted to host 110 forconcurrent abstraction and document review while the patient isreceiving care at the medical facility.

Host 110 may receive dictations and/or documents related to a patientfrom the communication channel. The received dictation and/or documentsmay be stored in data storage device 116 for processing by transcriptionapplication 122 into dictation into a text document. As part of theexchange between user 114 and host 110, transcription application 122can present an interactive user interface that provide instructions,warnings, and prompts to user 114 to enter information. For instance,transcription application 112 may prompt user 114 to dictate differenttypes of information in different segments, as described in U.S. Pat.No. 7,383,183, the disclosure of which is incorporated herein byreference in its entirety.

The transcribed document, as well as any other documents received fromdictation device 111 and/or user 113 may be submitted to abstractionapplication 124. The extractor module 113 analyzes each document todetermine a corresponding document type. The document type indicates acategory of a document based on identifying keywords in the document.For example, in the case of a patient's documents, keywords identifyinga document type can be “discharge summary,” “history and physicalconsultation,” “laboratory results,” “admission” and the like. Thekeyword “discharge summary” would identify the document type as adischarge summary.

Based on abstraction rules stored in storage device 116 that correspondto the document types, extractor module 113 may extract specific data.The abstraction rules are a plurality of rule sets which specify thedata to extract from a particular type of document.

The extractor module 113 may identify a document type and extracts datafrom the document corresponding to the data specified by one or morerules using natural language processing (NLP). Often, clinicalinformation generated by physician dictation is stored as free text in atranscribed document. Natural language processing allows for theconversion of the free text data into a computer-readable format so thatthe data may be used by other programs to automate applications. Forexample, prior to data extraction, a NLP engine using a dictionarylook-up approach can be used to normalize the document into a standardformat (e.g., formatting section title headers of the document withlogical observation identifiers names and codes).

Extractor module 113 includes NLP extractors, which are specific enginesfocused on extracting content from different types of documents. Any ofa variety of natural language processing techniques can be employed toperform the extractions. In some embodiments, a “bag of words”methodology can be used. An example of this methodology that is suitablefor use in the disclosed embodiments is described in “Natural LanguageProcessing Framework to Assess Clinical Conditions”, published in theJournal of American Medical Informatics Association, Volume 16, Number4, July/August 2009, written by Ware et al., the content of which isincorporated by reference herein in its entirety.

Linker module 115, when executed by controller 112, controls host 110 todetermines corresponding codes for all or part of the extractedinformation. Linker module 115 determines the corresponding codes usingnatural language processing. NLP linkers are engines focused onevaluating extracted information to determine a corresponding medicalcode. The codes may correspond to an industry standard coding systemsuch as, SNOMED (systemized nomenclature of medicine), RxNorm, ICD 9,and LOINC (logical observation identifiers names and codes). The NLPlinkers can use any natural language processing technique for codinginformation such as, regular expression (Regex) pattern matching andcontext evaluation.

User interface module 117, when executed by controller 112, controlshost 110 to present various interactive graphical user interfaces viaone or more of host 110, dictation device 111 or terminals 119 and 121for interacting with user 114, reviewer 118 or validator 120. Exemplaryinteractive graphic user interfaces provided by user interface module117 are illustrated in FIGS. 3A-4B, and described below. User interfacemodule 117, after extracting and coding information, may forward theinformation to workflow engine 119 for further processing.

FIG. 2 is a flow chart illustrating an exemplary abstraction and codingprocess. At step 201, host 110 receives one or more documents fromdictation device 111 and/or user 114. For example, host 120 can receivea patient's information from a hospital via a personal computer,including the patient's admission information, progress notes, procedurelists, lab results, history and physical, discharge summary. Thereceived dictations and/or documents may include patient specificinformation such as the following: names, mailing addresses, ages,dates, telephone numbers, fax numbers, e-mail addresses, social securitynumbers, medical record numbers, health plan beneficiary numbers,account numbers, certificate/license numbers, license plate numbers,vehicle identifiers, URL addresses, Internet Protocol address numbers,biometric identifiers, photographic images or any other informationwhich may be used to identify an individual. The information may alsoinclude non-private information such as, medication lists, allergies,procedure lists, quality measures, problem lists, present on admissiondiagnoses and guideline adherence information.

After being processed by transcription application 122, host 120 storesthe transcribed documents in data storage device 116 and provides thedocuments to abstraction application 124 along with any receiveddocuments that did not require transcription. The one or more documentscan be stored together in a patient's chart in data storage device 116.

At step 203, extractor module 113 searches each document for keywordsidentifying the document type. Once the document type is identified,extractor module 113 selects a rule set from the abstraction rulescorresponding to the document type for each document. The abstractionrules specify the information type(s) to extract from a particular typeof document. For example, an abstraction rule for a History and Physicalmay specify the extraction of medical problems. The selected rule setmay specify one or more information types for extraction for a documenttype. Other examples of information that can be extracted from varioustypes of reports include medications, problems, allergies, procedures,laboratory tests or results, quality measures, and adherence toguidelines.

At step 205, extractor module extracts the specified information fromthe documents based on identified keywords associated with medicalproblems. The NLP extractor can identify the format of the document andits corresponding section title headers, from the document type.Alternatively, during the transcription of a document, tags may havebeen inserted to identify individual section headers. For example,referring to FIG. 3A, a History and Physical document contains a “PastMedical History” section title, appearing in portion A1 of the screenimage. The words within that section may be represented as an unorderedcollection of words, disregarding grammar and even word order, and canbe searched for any words relating to medical problems. Any word foundrelating to a medical problem is extracted as shown in section A2 ofFIG. 3A.

Some extractors can employ a relatively simple set of filtering rules toidentify and retrieve desired information. For example, a “History andPhysical” document may include one or more of the keywords “CHF,”“Cardiomyopathy,” and “Congestive,” which may be keywords denotingcongestive heart failure (i.e., a medical problem). Extractor module 113can extract congestive heart failure as a medical problem from theHistory and Physical document that contains any of these keywords. Otherextractors may be based upon more complex filters. For instance, anextractor could verify if a guideline for Congestive Heart Failure hasbeen followed. An example of this type of filter is described in greaterdetail in U.S. patent application Ser. No. 12/265,495, the disclosure ofwhich is incorporated herein in its entirety.

At step 207, linker module 115 evaluates the extracted information todetermine an associated code for each extracted item of information.Each abstracted information type is linked to a particular codestandard. For example, medical problems are associated with SNOMED codesand medications can be associated with RxNorm codes. Each extractedinformation item can be mapped to a code using pattern matching andsearching algorithms. Linker module 115 searches a database of codes andterminologies, and a match may be found using pattern matching. A searchof associated concepts (e.g., synonyms of the extracted data andmedications associated with specific medical problems) are also searchedto find a pattern match.

Once a match is found, linker module 115 determines the context of thematched data based on evaluating neighboring words or phrases. Forexample, the phrase “arthritis” may be determined as a match for theextracted data “osteoarthritis.” The context evaluation determines thatthe phrase “rheumatoid” precedes “arthritis.” Since rheumatoid arthritisdescribes a different disease from osteoarthritis, it may be concludedthat the matched phrase “arthritis” is not a match. When linker module115 identifies a pattern match and context match, a code associated withthe match information may be linked to the extracted information. Thecodes can each be a unique numeric code (e.g., 57054005 is an associatedmedical code for the medical problem congestive heart failure).

At step 209, user interface module 117 presents a first interactivegraphic user interface to reviewer 118 for validation of the extractedinformation. Reviewer 118 examines the extracted information and addsany missed extractions and/or corrects inaccurate extractions using thefirst interactive graphic user interface.

FIGS. 3A-3C illustrate exemplary interactive graphic user interfacesthat may be presented to the reviewer for validation. In FIG. 3A, theproblems shown in the lower window of the user interface A2 have beenextracted from a History and Physical Document, which is shown in theupper window of the user interface A1. Reviewer 118 examines the sectionshown in the upper window, which illustrates where the information wasextracted from, to determine whether the information was extractedcorrectly. Based on reviewer 118's expertise in the field, (e.g.,reviewer 118 may be a doctor, nurse or medical abstractor), the reviewermay manually identify and correct inaccurate or missed extractions.

If an extracted term is not correct, for example, the term pertains to acondition of a patient's relative rather than the patient himself,reviewer 118 can remove the term by selecting on a delete box 301associated with the extracted term via the interactive graphic userinterface provided by user interface module 117. Conversely, if reviewer118 perceives that a problem identified in the document displayed in theupper window Al has not been extracted, the reviewer can add the problemto the list in the lower window A2 by clicking on “Add Problem” button302.

In FIG. 3B, the first interactive graphic user interface illustratesmedications extracted from a History and Physical Document, and in FIG.3C, the first interactive graphic user interface illustrates a list ofallergies extracted from the History and Physical Document. The lowerwindow A2 of the first user interface includes a column that lists asuggested code for each extracted concept, e.g. medical problem. When areviewer 118 selects one of the extracted elements shown in section A2of FIG. 3A, a second interactive graphic user interface is presented atstep 211.

FIG. 4A illustrates an exemplary coding process for extracted medicalproblems and FIG. 4B illustrates an exemplary coding process forextracted medications. The second interactive graphic user interface,illustrated in FIGS. 4A and 4B, is a search screen showing the resultsof the search performed for coding the extracted information, which mayoccur automatically after extraction. The forefront window of the secondinteractive graphic user interface illustrates a search string whichcorresponds to the selected extracted information (i.e., myocardialinfarction). The synonyms and associated concepts of the extractedinformation are also shown in the forefront window. All the patternmatches are shown in a search results pane 401, and the selected code isshown in a details pane 402. Reviewer 118 examines the details andvalidates the code, if the code is correct. If the code is incorrect,reviewer 118 may select an appropriate code from the search results inpane 401.

In some exemplary embodiments, the extracted information and/or thecoded information can be presented to multiple reviewers in succession.A first reviewer may review the information for accuracy and makesrevisions as necessary. Thereafter, the information may be presented toanother one of the reviewers to review for quality control. Theinformation can be presented to any number of reviewers in succession.

The generated reports can be submitted to a scrubber application forprocessing before the report is presented to a reviewer. The scrubberapplication searches the reports for private information, for example, alist of information items identified by HIPAA as protected healthinformation (PHI), and removes the private information from thedocuments. One example of a scrubber application is described in U.S.Pat. No. 7,383,183. The scrubbed reports are presented to reviewer 118for review. The reports can be stored in a queue for subsequent reviewby the reviewer 118.

Reviewers 118 can download one or more of the reports from the queue toreview, or the reviewer can receive the one or more reports after thereports have been scrubbed. Reviewer 118 performs abstraction and/orcoding review which may entail verifying the accuracy of the extractedand coded information. Reviewer 118 is typically not privy to patientprotected information and thus the reports presented to the reviewer arescrubbed beforehand to remove the patient's personal information.

At any time during the foregoing review processes, if reviewer 118 isnot certain about the results or requires further information to performthe validation, the reviewer may submit a query to host 110 forpresentment to validator 120 review to inquire about any ambiguities.Validator 120 may send host 110 a response to the query and the responseis presented to reviewer 118. Any one of several reviewers in thesuccession may check with host 110 to see if validator 120 has respondedto the request and update the report with the information or completevalidation of the information.

At step 213, the extracted information and selected codes or selectionof codes may be forwarded to the workflow engine for further processing.In some instance, the reviewer 118 may need to submit a query to thevalidator to complete workflow processing, as described below. In theseinstances, the selection of codes is forwarded to workflow engine 119.Workflow engine 119 may include processes including, a end-uservalidation process, a code set generation process forbilling/reimbursement, a quality measures (QA) process for reporting,and an alert generation process.

The end-user validation process presents a third interactive graphicuser interface, as illustrated in FIGS. 5A and 5B, to validator 120 forend user validation. FIGS. 5A and 5B illustrate end user validation ofthe information extracted. The third interactive graphic user interfacemay also illustrate the coded information for end user validation. InFIG. 5A, private information has been omitted (i.e., scrubbed) from theuser interface, whereas the view in FIG. 5B includes private informationsuch as, patient names.

Validator 120 reviews the information and validates the information ifcorrect. Referring to FIG. 5A, at the top of the window is a list 501 ofabstracted documents that are currently available for validator 120 toreview. Text from a selected document, such as the “Medications”section, appears in a lower left pane 502 of the window, and theabstracted concepts appear in a lower right pane 503. In the illustratedexample, validator 120 has opened the list of abstracted medications forreview. Each listed medication is accompanied by a button 504 thatprovides validator 120 with the ability to expand the listing to reviewdetails about the medication. Referring to FIG. 5B, the listing for“Aspirin” has been expanded to identify the delivery route, strength,duration and dosage for the medication. Each listed medication may alsobe accompanied by a delete button 505 to remove the listing if validator120 does not feel that it is correct. The information is validated whenvalidator 120 accepts the information by checking a button 506 in theupper pane to sign the document.

In an exemplary embodiment, host 110 receives an identification andpassword from validator 120. Host 110 verifies whether the validator isauthorized to receive private information using the ID and password. Ifvalidator 120 is authorized to receive private information, theinformation is presented to the validator with the private information,as illustrated in FIG. 5B.

The end-user validation process generates a report of the validatedinformation for storage in storage device 116. The report can bestructured in any format such as, the clinical documentationarchitecture. The report may include a report number and document type.Optionally, the generated report may be submitted to a scrubberapplication for removing private information before storage in thestorage device.

Workflow engine 119 executes the code set for billing and reimbursementprocess when outputting information for billing and/or reimbursement.Reviewer 118 submits a query to validator 120 to inquire aboutparticular codes needed for billing and reimbursement. Reviewer 118receives the response and selects the code set from the selection ofcodes forwarded to the workflow engine as stipulated by validator 120.The process may generate an output (e.g., display or document) forbilling and/or reimbursement.

Reviewer 118 may submit a query to validator 120 to inquire aboutinformation extracted and coded for processing during the qualityassurance measures for the reporting process. Reviewer 118 uses thereceived information from validator 120 to check quality measures basedon the extracted and coded information. The process generates an outputfor reporting the results of the quality measures.

The alert generation process triggers an alert when pre-definedconditions are met, e.g. absence of a required treatment in a clinicalguideline. Reviewer 118 reviews the extracted and coded information todetermine if any conditions are satisfied. If so, an alert may betriggered in host 110.

All of the steps above discussed above or illustrated in FIG. 2 may beperformed continuously and/or concurrently with a period during which apatient is receiving care at a medical facility, for example, ahospital. As disclosed herein, embodiments and features can beimplemented through computer hardware and software. Such embodiments canbe implemented in various environments such as networked andcomputing-based environments with one or more users. The presentdisclosure, however, is not limited to such examples, and embodimentscan be implemented with other platforms and in other environments.

Moreover, while illustrative embodiments have been described herein,further embodiments can include equivalent elements, modifications,omissions, combinations (e.g., of aspects across various embodiments),adaptations and/or alterations as would be appreciated by those in theart based on the present disclosure.

Other embodiments of this disclosure will be apparent to those skilledin the art from consideration of the specification and practice of theembodiments of the embodiments disclosed herein. Further, the steps ofthe disclosed methods can be modified in various manners, including byreordering steps, executing multiple steps concurrently, and/orinserting or deleting steps, without departing from the principles ofthe disclosed. It is therefore intended that the specification andembodiments be considered as exemplary only.

1. A method of abstracting and coding information by a computerincluding: a processor, an information storage device, a display device,and a user-input device, said method comprising: extracting by theprocessor information from a record based on extraction rules stored inthe information storage device, said extraction rules corresponding toan identified record type; determining by the processor a plurality ofcodes corresponding to the information extracted from the record, saidcodes belonging to one or more sets of codes stored in the informationstorage device; presenting on the display device the correspondencebetween the extracted information and the codes; receiving from theuser-input device a validation of the correspondence between theextracted information and one of the codes; and outputting by theprocessor a report including the validated information and the validatedcode. 2-20. (canceled)